Multimedia Broadcast/Multicast Service (MBMS) is a broadcasting service offered via cellular networks including Wideband Code Division Multiple Access (WCDMA) and Long Term Evolution (LTE). MBMS is a point-to-multipoint or multicast service in which data is transmitted from a single source entity to multiple destination recipients. The MBMS service can be used for both file download and for streaming services, such as Mobile TV. Enhanced MBMS (eMBMS) is used to denominate an MBMS service in Evolved Packet Systems including the Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) or Long Term Evolution (LTE). In the present disclosure, the term MBMS is used generally to refer to either or both of the MBMS and eMBMS services.
The MBMS network architecture, node functions, control plane protocol architecture and user plane protocol architecture are defined in “E-UTRAN overall description”, 3GPP TS 36.300 (“TS 36.300”), which is incorporated by reference in its entirety herein. An example embodiment of this architecture is illustrated in FIG. 1, which shows the MBMS deployment in an LTE network with a distributed Multi-Cell/Multicast Coordination Entity (MCE) architecture, where the MCE is distributed and co-located with each E-UTRAN NodeB (eNB).
A Broadcast-Multicast Service Center (BM-SC) 100 originates the MBMS session, using content from at least one content provider 102. The BM-SC is connected to user plane (UP) 104 and control plane (CP) 106 components of at least one MBMS Gateway (MBMS-GW) 108 by an SGi-mb UP interface 110 and an SGmb CP interface 112 respectively. The CP component 106 of the MBMS-GW 108 is connected to a Mobile Management Entity (MME) 114 along a Sm CP interface 116.
The SGi-mb 110, SGmb 112 and Sm 116 interfaces run over a unicast internet protocol (IP) (either IPv4 or IPv6) network.
In some example embodiments, the BM-SC 100 can be connected to a public data network (PDN) gateway 118 by an SGi interface 120.
The MME 114 communicates with the MCE 122a/122b in an eNB 124a/124b along an M3 CP interface 126a/126b. Two eNBs 124a/124b are shown in the network for exemplary purposes. The UP component 104 of the MBMS-GW 108 communicates with the MCE 122a/122b along an M1 interface 128a/128b. The E-UTRAN M3 Application Protocol is described in 3GPP TS 36.444 (“TS 36.444”), which is incorporated by reference in its entirety herein.
The CP interfaces are the SGmb 112, Sm 116 and M3 126a/126b interfaces. The CP interfaces do not carry any user data but are responsible for the signaling procedures to establish or terminate MBMS sessions along unicast IP (either IPv4 or IPv6) networks.
The UP interfaces are the SGi-mb 110 and M1 128a/128b interfaces. The M1 interface 128a/128b is responsible for establishing the multicast listening and Protocol Independent Multicast (PIM) protocol states, as well as the related shortest path distribution tree carrying the MBMS user data and synchronization data.
Each eNB 124a/124b may be connected along a E-UTRAN Uu interface 130 with at least one user equipment (UE) 132. One UE 132 is shown for exemplary purposes.
FIG. 2 illustrates an alternative example embodiment of the MBMS deployment in an LTE network, in which the MCE is not co-located with each eNB, but rather is a stand-alone component or optionally part of another network element (not shown), leading to a centralized MCE architecture.
In the embodiment of FIG. 2, the centralized MCE 134 communicates with the MME 114 along an M3 CP interface 126c, while the MCE 134 communicates with each eNB 124a/124b along an M2 CP interface 136a/136b. The E-UTRAN M2 Application Protocol, described in 3GPP TS 36.443 (“TS 36.443”), which is incorporated by reference in its entirety herein, also does not carry any user data and runs over unicast IP (IPv4 or IPv6) networks.
As with FIG. 1, the UP component 104 of the MBMS-GW 108 communicates with each eNB 124a/124b along an M1 UP interface 128a/128b. 
FIG. 3 illustrates an example embodiment of data (user plane) traffic through the example embodiments shown in FIGS. 1 and 2. MBMS packets are encapsulated in MBMS Synchronization Protocol (SYNC) Protocol Data Units (PDUs), described in “MBMS Synchronization Protocol (SYNC)”, 3GPP TS 25.446 (“TS 25.446”), which is incorporated by reference in its entirety herein.
One SYNC instance 140 is supported per MBMS bearer. The SYNC protocol terminates at the eNB 124a, which is responsible for transmitting the MBMS packet 142 over the Uu interface 130 to the UE 132.
The MBMS-GW 108 allocates a GPRS Tunneling Protocol (GTP) User (GTP-U) tunnel 144 for each MBMS bearer. The GTP-U tunneling protocol is described in “GPRS Tunneling Protocol User Plane (GTPv1-U)”, 3GPP TS 29.281 (“TS 29.281”), which is incorporated by reference in its entirety herein. In some example embodiments, at the eNB 124a, the socket used for terminating all GTP multicast tunnels is UDP port 2152.
The MBMS bearer runs over an IP multicast network 146 using a source-specific multicast (SSM) channel, described in “An Overview of Source-Specific Multicast”, IETF RFC 3569 (“RFC 3569”), which is incorporated by reference in its entirety herein, where the source of the SSM channel is the MBMS-GW 108. Each SSM channel is a unidirectional shortest path distribution tree from a specific source IP address. Each SSM channel is uniquely identified by, in some example embodiments, the combination of an SSM destination address G (a multicast IPv4 address in the range 232/8 or a multicast IPv6 address with prefix FF3x::/32) and a source IP address S (an IPv4 or IPv6 unicast address belonging to the MBMS-GW). The SSM channel is constructed by PIM routers using the PIM sparse mode (SM) (PIM-SM) protocol described in “Protocol Independent Multicast—Sparse Mode”, IETF RFC 4601 (“RFC 4601”), which is incorporated by reference in its entirety herein.
The eNB 124a requests interest in receiving IP multicast packets for a specific SSM channel. Accordingly, the eNB124a is considered an SSM receiver or listener. It uses the Internet Group Management Protocol (IGMP) Version 3 (IGMPv3) protocol or the Multicast Listener Discover (MLD) Version 2 (MLDv2) protocol to communicate with the PIM routers. The IGMPv3 protocol is described in “Internet Group Management Protocol Version 3 (IGMPv3)”, IETF RFC 3810 (“RFC 3810”), which is incorporated by reference in its entirety herein, and the MLDv2 protocol is described in “Multicast Listener Discovery Version 2 (MLDv2)”, IETF RFC 3810 (“RFC 3810”), which is incorporated by reference in its entirety herein.
An MBMS bearer can be local, regional or national in reach, and may span more than a thousand eNBs and a considerably larger number of UEs connected to these eNBs.
The lack of user plane connectivity monitoring and fault indication between an eNB and a BM-SC can directly impact MBMS service deployment in mobile operator networks because of concerns with performance degradation and potential holes in the multicast service coverage. Any link, node, multicast state or reverse path forwarding (RPF) failure in the IP multicast network can potentially cause undetected MBMS service interruption.
Operators have attempted to address these concerns by adding redundancy to the IP multicast network, where economically feasible, in order to re-route traffic under specific and well-known failure scenarios. Such redundancy schemes, however, are expensive and may not address all possible failure cases, especially those failures that may not be easily detectable at the physical (link) layer.
3GPP specifications do not address methods for the system to detect an M1 user plane interface loss of connectivity or MBMS bearer loss of service continuity to a specific eNB.
The SYNC and GTP-U protocols do not provide any fault detection mechanisms for multicast bearers. For example, TS 29.281 provides that bidirectional GTP-U path management messages such as, by way of non-limiting example, Echo Request and/or Echo Response shall not be used for MBMS IP multicast distribution.
In any event, existing bidirectional echoes or pings may not provide an accurate view of the multicast network connectivity since the set of eNB receivers may be unknown to the MBMS-GW (source) sender, which is provided neither the number nor the identity of the eNB receivers (destination).
The Bidirectional Forwarding Detection (BFD) protocol described by the IETF in “Bidirectional Forwarding Detection”, RFC 5880 (“RFC 5880”), which is incorporated by reference in its entirety herein, may be used to monitor IP unicast connectivity between two BFD-capable nodes. Unicast BFD can detect a link failure between two direct peers and immediately notify the unicast or multicast routing table. Such failure detection will trigger the PIM-SM protocol running on these nodes to send and propagate PIM joint messages upstream over an alternate path towards the source S, in order to reconstruct the (S,G) multicast tree state, in order to forward the MBMS packets around the link failure.
However, unicast BFD makes use of a BFD session on each link in the network. The use of such BFD capability is not available in conjunction with IP multicast communications on many routers. As well, BFD does not detect many UP problems, such as, by way of non-limiting example, multicast channel state and RPF failure, that could impact the end-to-end MBMS UP bearer, including, without limitation, internal faults at the head or tail of the MBMS service, within the MBMS-GW or eNB respectively.
Therefore, it would be desirable to provide a system and method that obviate or mitigate the above described problems.